Design and Development of Dependability Case Architecture during System Development

A dependability case communicates an argument that a system will acceptably operate with respect to the stakeholders’ envisioned dependability requirements. We describe the use of the Goal Structuring Notation (an argumentation notation and methodology) for dependability case development to establish arguments supporting claims of achievement of the dependability requirements. At each stage of the evolution of the safety case, the dependability argument is expressed in terms of what is known about the system being developed, providing at the same time feedback to the design process. As design knowledge increases during the project, the goals (and the corresponding arguments) can be expressed in increasingly tangible and specific terms. A case can consist of a number of self-contained GSN argument modules each of which reasons about an individual aspect of the system. The resulting dependability case architecture is structured according to how the argument modules are associated during the evolution of the case. This paper presents how a dependability case can be architected throughout the lifecycle of a system, using GSN contracts to capture the associations between the argument modules of the case. Furthermore, the paper introduces the dependability profile, a concept used to facilitate structuring the dependability arguments. The dependability profile is created during the analysis of the system and describes acceptable behaviour of the elements in the system model. The paper uses the UK defence architectural framework MODAF to illustrate the links between system modelling and dependability case architecture. Introduction Similarly to a safety case, a dependability case is a device for communicating ideas and information, usually to a third party. In the example of the safety case this can be a regulator or certification authority. Although dependability cases are not a requirement in the same manner as safety cases – For example the UK Defence Standard 00-56 (ref 1) explicitly asks for a safety case to accompany a system – constructing an argument about the dependability properties of a system, such as safety availability and performance, contributes in establishing assurance about the overall dependability behaviour of a system. The Goal Structuring Notation is used in a dependability case to structure the argument about acceptable fulfilment of the system’s dependability goals. GSN goals are specific claims that a system has achieved a particular requirement (ref 2). Being able to explicitly represent and associate all the elements of an argument, GSN helps to articulate post-conditions for the initially identified requirements of the system in question. At each stage of the evolution of the safety case, the dependability argument is expressed in terms of what is known about the system being developed. For example, at the early stages of project development the dependability argument is related to the highlevel objectives as conceived by the stakeholders in the concept of operations (CONOPS), whereas in later stages is related to detailed behaviour of system components or subsystems. GSN allows the creation of modules, which are self-contained arguments, providing a number of benefits to the dependability case (ref 3). Argument modules can focus on a number of different aspects of the system development including not only arguments regarding the system as artefact (product arguments), but also arguments regarding the development process (process arguments). The final dependability case is composed by combining the appropriate argument modules during system development. Development of the Dependability Case Evolving in parallel to the system, goals are decomposed until they can be directly supported by evidence collected during the development and testing phases of the system. Previous work from the authors proposes three methodologies which collaborate during the evolution of the dependability case. The participant methodologies collaborate during the evolution of the dependability argument, which itself is based on the Goal Structuring Notation (GSN) methodology and notation. Similarly to the twin peaks paradigm (ref 4), evolution of the system and the argument is an iterative process, which involves making decisions about the architecture and the design of the system that need to be justified and documented. Interaction between the argument and the design process exists during the evolution of the system. The evolving argument should serve to evaluate the design’s fitness to satisfy the stated dependability goals. A design that directly addresses the stated goals will result in a strong argument. If the stakeholders involved in the development of the argument deem that the argument is not satisfactory, changes to the design will have to be made. The argument of a dependability case can constitute the interface between evolution of requirements and design, providing a systematic way of documenting, tracing and reasoning about decisions.